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REMARKS 

Reconsideration and allowance of the subject application are respectfully requested. 

The Examiner objects to claim 9 noting a typographical error in the dependency. Claim 9 
has been amended so that it now depends from claim 8 as initially intended. 

Claim 1-8, 10-34, and 38-41 stand rejected under 35 U.S.C. §102(e) as being anticipated 
by U.S. Patent Publication 2001/0027490 to Fodor et al. This rejection is respectfully traversed. 

To establish that a claim is anticipated, the Examiner must point out where each and 
every limitation in the claim is found in a single prior art reference. Scripps Clinic & Research 
Found, v. Genentec, Inc., 927 R2d 1565 (Fed. Cir. 1991). Every limitation contained in the 
claims must be present in the reference, and if even one limitation is missing from the reference, 
then it does not anticipate the claim. Kloster Speedsteel AB v. Crucible, Inc., 793 F.2d 1565 
(Fed. Cir. 1986). Fodor fails to satisfy this rigorous standard. 

Fodor describes an RSVP proxy that originates the RES V message as part of the RS VP 
protocol in response to an incoming PATH message on behalf of one or more receivers identified 
by the PATH message. As Fodor explains, the RSVP proxy acts on behalf of the remote host 
and facilitates resource reservation between the originating host and the RSVP proxy as shown in 
Figure 3. This figure is the very same figure shown in Figure 2 of the instant application. But 
Fodor does not address the problem of how to establish a protocol proxy relationship in a 
multimedia session involving a mobile communication access network in a non-enabled mobile 
terminal. Indeed, the Examiner should understand that RSVP is a protocol developed for use 
with the wired line internet. No special provisions are established in RSVP signaling and RSVP 
proxies for these specific issues that arise in mobile communications with non-RSVP enabled 
mobile radio terminals. 
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The inventors of the instant application recognized this problem and provided a 
mechanism that allows a non-enabled mobile terminal to communicate a protocol proxy request 
with an enabled node along the send-receive path between the mobile terminal and a remote host. 
In addition, a mechanism is provided to install information in the enabled node so that the node 
can function as the protocol proxy for the non-enabled mobile host. 

The Examiner relies upon Fodor's Figure 5 and the text at paragraphs 165 and 166. A 
comparison of Figure 25 in Fodor and Figure 6 in the instant application reveals that there is no 
RSVP proxy identified with any node in the UMTS/GPRS core network node including the 
SGSN and the GGSN in Figure 25 as there is in Figure 6 of the instant application. Figure 26 of 
Fodor clearly shows the mobile terminal is an RSVP -enabled mobile terminal. The RESV and 
PATH messages communicate directly from/to the mobile terminal (MT). In contrast, Figure 10 
of the instant application shows that the mobile terminal (labeled as user equipment UE-A) is not 
an RSVP-enabled host. The RSVP messages are not originated or received by the UE. As a 
result, the mobile terminal needs an RSVP proxy, which is performed by the GGSN, to originate 
and receive RSVP messages on its behalf. Indeed, when the UE activates or modifies a second 
PDP context, as shown in Figure 10, it requests (via the SGSN) that the GGSN perform the 
RSVP proxy role by setting an RSVP proxy flag. No such signaling between the mobile 
terminal and the GGSN is performed in Figure 26 of Fodor requesting that the GGSN perform a 
proxy role or providing any kind of proxy indicator to ask that the GGSN perform a proxy role 
for the mobile terminal. 

In paragraph 165, Fodor states explicitly that "an RSVP proxy in a performance 
enhancement mode is inserted at the MT. n Fodor explains that this is done to improve the 
reliability of the RSVP session as well as to reduce the amount of signaling over the radio 
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interface. Thus, the text in paragraph 166 relates to the RSVP proxy inserted into the mobile 
terminal itself. The text in this paragraph further explains that "when the MT receives the PATH 
message, . . . when the RESV response is received by the MT." In contrast, independent claim 1 
recites that the mobile terminal sends a message requesting that the access point function as a 
proxy "for the mobile terminal." In Fodor, the mobile terminal (MT) receives the RSVP protocol 
messages directly— it does not need RSVP proxy. The mobile terminal is an RSVP-proxy for its 
terminal equipment (TE). 

Similarly, in claim 8, there is no teaching in Fodor that the GGSN receives from the 
mobile terminal MT a request message with an indicator "indicating that the access point should 
function as a communications protocol proxy for the mobile terminal for the media data stream 
of the multimedia session." Indeed, the mobile terminal directly receives and transmits RSVP 
messages. The GGSN does not perform "as the communications protocol proxy for the mobile 
terminal," as required by independent claim 8. Similar distinctions are present for independent 
claims 18, 25, and 38. 

Claims 35-37 stand rejected under 35 U.S.C. §102(e) as anticipated by U.S. 
Patent 6,654,610 to Chen. This rejection is respectfully traversed. 

The Examiner relies on Figure 7 and various text passages in Chen to contend that Chen 
includes a PDP configuration options (PCO) field that "includes an indicator indicating whether 
the access point should function as a communications protocol proxy for the mobile terminal for 
the media data stream of the multimedia session." Applicants respectfully disagree. 

The teachings in Chen simply relate to a standard RSVP resource negotiation procedure. 
The flag bits that are set relate to the quality of service information which may be specified for 
the uplink as well as for the downlink. The assumption, as in Fodor, is that the mobile terminal 
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is RSVP-enabled. Chen's mobile terminal doesn't need an RSVP proxy. Indeed, in the scenario 
described in column 4, Chen explicitly assumes that the terminal equipment 32 and the mobile 
station 30 "generate RSVP signaling messages." See column 4, lines 27-28. Moreover, at 
column 10, beginning at line 1 1 (referred to by the Examiner), Chen explains that the mobile 
terminal MT receives "both a first-time RESV message from TE and a first-time RESV message 
forwarded by GGSN." Like Fodor, Chen's mobile terminal is performing a proxy role for the 
terminal equipment TE which corresponds to a non-UMTS specific application supported by the 
mobile terminal. 

Since both Fodor and Chen fail to disclose or suggest a mobile terminal that is not 
enabled to perform RSVP protocol communications signaling, it makes complete sense that 
neither reference describes the mobile terminal sending a request message to an access point 
requesting the access point to function as an RSVP proxy for the mobile terminal. An RSVP- 
enabled terminal doesn't need an RSVP proxy. The rejection should be withdrawn, and the 
application passed to allowance. 
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